home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 45 < prev    next >
Internet Message Format  |  1994-08-27  |  1KB
  1. Date: Mon, 30 May 1994 15:39:21 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Re: Colour.
  4. To: gem-list@world.std.com
  5. In-Reply-To: <199405301408.QAA08792@blade.stack.urc.tue.nl>
  6. Message-Id: <Pine.3.87.9405301521.D17681-0100000@undergrad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11.  
  12. On Mon, 30 May 1994, Erlend Nagel wrote:
  13.  
  14. > 
  15. > Simon Gornall wrote:
  16. > 
  17. > > A program (GEMCMS.PRG) in the auto folder could register the cookie, and
  18. > > reserve mem for (say) 30 apps. Have a .cpx that llows you to configure this on
  19. > > the fly, and then you just need binding support (libgem.olb could incorporate
  20. > > it easily, lattice/pure/any other may have more difficulty - for these a 
  21. > > separate lib may be necessary.)
  22. > 
  23. > I don't like the idea of having a certain limit of applications a colour
  24. > manager can handle, even if it is user configurable. I'd say especially
  25. > if it is user-configurable. I consider myself a pretty standard user
  26. > (whatever that is) and I don't like it when I have to configure things.
  27. > It is best I think if our colour manager would allocate memory on the
  28. > dynamically.
  29. > 
  30. > Erlend.
  31. > 
  32.  
  33. No limits, please.  The manager should use the handle of each window as 
  34. the handle the app will use when setting/resetting a palette.  When a 
  35. window is topped/untopped, the app should pass the window handle and a 
  36. flag for whether the window was topped or untopped.  This way, the system 
  37. could manage a seperate palette for each WINDOW.
  38.  
  39.  
  40.